Связь между процессами – это суть распределенных систем [1].. Взаимодействие в распределенных системах всегда базируется на низкоуровневом механизме передачи сообщений, предоставляемом базовой сетью. Чтобы упростить разработку больших приложений используются различные модели взаимодействия. Наиболее распространенными являются: удаленный вызов процедур (Remote Procedure Call, RPC), удаленное обращение к методам (Remote Method Invocation, RMI), ориентированный на сообщения промежуточный уровень (Message-Oriented Middleware, MOM).
   Удаленный вызов процедур позволяет программам вызывать процедуры находящиеся на других машинах. Когда процесс, запущенный на машине А, вызывает процедуру с машины В, вызывающий процесс на машине А приостанавливается, а выполнение вызванной процедуры происходит на машине В [1]. Информация может быть передана от вызывающего процесса вызываемой процедуре через параметры и возвращена процессу в виде результата выполнения процедуры.
   В RPC удаленный вызов процедур выглядит точно также, как и локальный, таким образом вызов процедур является прозрачным. Если необходимо обратится к удаленной процедуре, то вызывается клиентская заглушка. Она упаковывает параметры вызова в сообщение и пересылает это сообщение на сервер, после чего заглушка блокируется до получения ответа. Когда сообщение приходит на сервер, операционная система сервера передает его серверной заглушке, которая эквивалентна клиентской, но работает на стороне сервера. После получения сообщения серверная заглушка извлекает из него параметры и вызывает процедуру сервера. Когда серверная заглушка после окончания обработки вызова возвращает управление вызвавшей программе, она запаковывает результаты в сообщение и посылает его как код возврата. Упаковка параметров в сообщение называется маршалингом. Параметры могут передаваться в процедуру по ссылке либо по значению. В случае передачи по значению параметры просто копируются в сообщение и пересылаются. При передаче по ссылке дело обстоит сложнее, так как ссылка это адрес в памяти и он не будет действительным на другой машине. Для решения проблемы, в сообщение может копироваться структура данных, на которую указывает ссылка или копироваться реальное значение ссылки и потом генерироваться специальный код в процедурах сервера для работы с ней.
   Для сокрытия механизма удаленного вызова процедуры требуется, чтобы обе стороны следовали одному протоколу взаимодействия. Также необходимо, чтобы клиент и сервер пришли к договоренности по вопросу представления простых типов данных, таких как целые числа, символы, логические значения и так далее. После определения протокола необходимо организовать клиентские и серверные заглушки. Заглушки работающие по одному протоколу, для разных процедур различаются лишь интерфейсом с приложениями. Интерфейс состоит из набора процедур, которые могут быть вызваны клиентом, но реализуются на сервере. Для упрощения работы, интерфейсы часто описываются с использованием языка определения интерфейсов (Interface Definition Language, IDL). Интерфейс, определенный на IDL, компилируется затем в заглушки клиента и сервера.
   Объектно-ориентированная технология показала свое значение при разработке нераспределенных приложений. Одним из наиболее важных свойств объекта является то, что он скрывает свое внутреннее строение от внешнего мира посредством строго определенного интерфейса. Такой подход позволяет легко изменять или заменять объект, оставляя интерфейс неизменным. Объект инкапсулирует данные (состояние) и операции над этими данными (методы). Доступ к методам можно получить через интерфейс. Единственным способом изменять состояние объекта, является использование его методов. Объект может реализовывать множество интерфейсов. Разделение на интерфейсы и объекты позволяет помещать интерфейс на одну машину, а сам объект на другую.
   Когда клиент осуществляет привязку к распределенному объекту, в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем. Заместитель клиента аналогичен клиентской заглушке в RPC. Единственное что он делает это выполняет маршалинг параметров в сообщения при обращении к методам и демаршалинг данных из ответных сообщений. Сами объекты находятся на сервере и предоставляют необходимые клиентам интерфейсы. Входной запрос на обращение к методу попадает сначала на серверную заглушку (скелетон). Скелетон преобразовывает его в правильное обращение к методу через интерфейс объекта находящегося на сервере. Серверная заглушка также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента.
   Характерной особенностью большинства распределенных объектов является то что, их состояние локализовано на одной машине. Объекты делятся на сохранные и нерезидентные. Сохранный объект продолжает существовать даже не находясь постоянно в адресном пространстве серверного процесса, то есть не зависит от текущего состояния сервера. Нерезидентный объект существует только пока сервер управляет им. Когда сервер завершает работу, объект прекращает свое существование. Обычно распределенная система объектов предоставляет ссылки на объекты уникальные в пределах системы. Такие ссылки можно передавать между процессами, запущенными на различных машинах. Когда процесс обращается к объекту по ссылке, он сначала должен выполнить привязку к объекту, результатом которой будет заместитель в адресном пространстве процесса.
   Ссылки на объект должны содержать достаточно информации для обеспечения клиентам привязку к объекту. Ссылка должна содержать сетевой адрес машины, на которой размещен объект, конечную точку, определяющую сервер, и идентификатор объекта. Однако в процессе работы могут меняться адрес машины и конечная точка, поэтому ссылки станут недействительными. Для решения этой проблемы может использоваться сервер локализации, следящий за работой серверов, на которых расположены объекты. Ссылка на объект в результате должна содержать сетевой адрес сервера локализации, а также действующий в системе идентификатор сервера.
   Так как ссылки на объекты поддерживаются в пределах системы, то возможности по передаче параметров при обращениях к методам не столь ограничены, как в случае RPC. При обращениях к методам ссылки на распределенные объекты постоянно используются как параметры. Ссылки передаются по значению и копируются с одной машины на другую. Если процесс получает ссылку на объект в качестве результата обращения к методу, он легко может выполнить привязку к объекту, на который указывает ссылка.

   В распределенных системах понятие процесса играет большую роль. Операционная система изолирует приложения по отдельным процессам. По сути дела, процесс формирует границу вокруг кода и данных приложения. Все данные и адреса памяти определяются относительно процесса, и код, исполняющийся внутри одного процесса, не имеет доступа к памяти другого процесса, если не используется какой-либо механизм коммуникаций между процессами. Значительное преимущество подобной изоляции адресных пространств повышает отказоустойчивость, так как сбой одного процесса не влияет на другие. Изоляция адресных пространств также не позволяет коду внутри одного процесса напрямую манипулировать данными другого процесса. Однако дробление процесса на несколько потоков выполнения упрощает построение распределенной системы и позволяет добиться лучшей производительности, благодаря тому, что переключение между потоками осуществляется значительно быстрее, чем между процессами. Важным свойством потоков выполнения является удобная реализация блокирующих вызовов, которые происходят без блокирования всего процесса на время выполнения потока.
   Сервер – это процесс, реализующий некоторую службу, требующуюся группе клиентов. Все серверы работают схожим образом. Они ожидают входного сообщения, посылаемого клиентом, затем проверяют это сообщение на правильность, после чего ожидают следующего сообщения. Серверы могут быть реализованы различными способами. В случае итеративного сервера он сам обрабатывает запрос и при необходимости возвращает ответное сообщение клиенту. Параллельный сервер не обрабатывает сообщение сам, а передает его в отдельный поток выполнения или другому процессу, после чего сразу же переходит в состояние ожидания следующего входного сообщения. Клиенты также могут быть многопоточными. Если клиенту, например надо получить несколько файлов от сервера, который сильно загружен, он может установить несколько соединений с различными репликами сервера.
   Важным типом сервера является сервер объектов, который ориентирован на поддержку распределенных объектов. Сам по себе сервер не предоставляет конкретной службы. Конкретные службы реализуются объектами, расположенными на сервере. Сервер предоставляет только средства обращения к локальным объектам на основе запросов от удаленных клиентов. Таким образом можно относительно легко изменять набор служб, просто добавляя или удаляя объекты. Сервер может поддерживать различные правила обработки объектов. Например нерезидентные объекты могут создаваться при первом запросе к нему, а уничтожатся, после того как не останется с ним связанных клиентов. Преимущество этого подхода состоит в том, что нерезидентные объекты нуждаются в ресурсах сервера только до тех пор, пока в этих объектах есть необходимость. Недостаток в том, что обращение может потребовать определенного времени для создания объекта. Можно создавать все нерезидентные объекты при инициализации сервера, однако будут выделяться ресурсы даже тем объектам, которые ни разу не будут использоваться.
   Таким же образом существует несколько подходов к использованию потоков выполнения. Сервер может содержать единственный управляющий поток выполнения. С другой стороны отдельный поток выполнения может создаваться для каждого объекта. В случае прихода запроса с обращением к объекту сервер просто передает запрос потоку выполнения, который отвечает за этот объект. Можно также выделять отдельный поток для каждого запроса. Независимо от способа назначения потока, необходимо решить создавать каждый поток по запросу или поддерживать пул потоков.

   Очень важным свойством распределенной системы является ее защищенность. Защита должна пронизывать всю систему целиком. Единственная брешь в системе защиты может сделать бесполезными все предпринимаемые меры обеспечения безопасности. Защита в компьютерных системах жестко связана с понятием надежности. Надежной компьютерной системой считается система, службам которой мы оправдано доверяем [1]. Рассматривая защиту системы, можно считать, что мы пытаемся защитить службы и данные от угроз защиты. Можно выделить четыре типа угроз защите[1]: перехват, прерывание, модификация, подделка.
   Перехват – это ситуация, когда неавторизованный агент получает доступ к службам или данным, например, когда связь между двумя агентами подслушивает кто-то третий.
   Прерывания – это ситуация, когда службы становятся недоступными, уничтожаются, их невозможно использовать, например, повреждение или потеря файла.
   Модификация включает в себя неавторизованные изменения данных или фальсификацию служб с тем, чтобы они не соответствовали своему оригинальному предназначению, например, перехват сообщений с последующим изменением передаваемых данных или изменение программ.
   Подделка – это ситуация, когда создаются дополнительные данные или осуществляется деятельность, невозможная в нормальных условиях, например, когда злоумышленник добавляет запись в файл паролей или базу данных.
   При построении системы защиты нужно не просто обеспечивать противостояние всевозможным угрозам защите, а описывать правила защиты, которые точно описывают разрешенные и запрещенные действия для пользователей, служб и т.д. После составления правил можно сосредоточиться на механизмах защиты, посредством которых реализуются эти правила. Наиболее важные из них: шифрование, аутентификация, авторизация, аудит.
   Шифрование преобразовывает данные, чтобы злоумышленник не мог их понять. Кроме того, оно позволяет проверить целостность данных.
   Аутентификация использует для проверки заявленного имени пользователя, клиента, сервера и пр. До начала работы службы с клиентом служба должна определить подлинность клиента. Обычно пользователи аутентифицируют себя при помощи пароля.
   Авторизация выполняется для проверки, имеет ли клиент право на выполнение запрашиваемых действий, например, доступ к базе данных.
   Средства аудита используются для контроля за тем, что делает клиент и как он это делает. Хотя средства аудита не защищают от угроз защите, журналы аудита постоянно используются для анализа «дыр» в системах защиты с последующим принятием мер против нарушителей.
   Организуя защиту распределенных приложений, можно использовать три основных подхода. Первый подход – это защита непосредственно ассоциированных с приложением данных. Основная ее задача сохранить целостность данных в независимости от того, какие с ними могут производиться операции. Второй подход – это защита путем точного указания того, кто и как может использовать операции доступа к данным или ресурсам. Например, в системе, построенной на основе объектов, для каждого из методов, доступ к которым открывается клиентам, можно указать, какой именно клиент имеет право к нему обратиться. Третий подход – сосредоточить внимание непосредственно на пользователе, приняв меры, чтобы доступ к приложению имели только определенные люди, независимо от операций, которые они собираются производить. Например, в университетах доступ к некоторым данным может быть разрешен только преподавателям и персонала, а студентам закрыт. При этом подходе управление сведено к определению ролей пользователей. После подтверждения соответствующей роли ей предоставляется или запрещается доступ к соответствующим ресурсам. В процессе разработки системы защиты определяются роли, которые могут понадобиться пользователям, и предоставляются механизмы управления доступом на основе списка ролей.

   .NET – это новая модель для создания приложений (пока только под Windows). С точки зрения программиста .NET вполне можно рассматривать просто как новую среду выполнения и новую библиотеку базовых классов [3]. Среда выполнения обеспечивается с помощью Common Language Runtime (CLR, стандартная среда выполнения для языков). При компиляции кода для .NET компилятор генерирует код на общем промежуточном языке (common intermediate language, CIL), а не традиционный код, состоящий из процессорных команд. При исполнении CLR транслирует CIL в команды процессора. Поскольку трансляция выполняется в период выполнения, генерируются команды конкретного процессора. Это значит, что приложение .NET можно развертывать на любой машине, где работает CLR и FCL (Framework Class Library – базовая библиотека классов). .NET позволяет интегрироваться разным языкам, т.е. одному языку использовать типы созданные на других языках. Например, CLR позволяет создать класс на С++, производный от класса, реализованного на Visual Basic. CLR делает это возможным, так как она определяет и предоставляет общую систему типов (Common Type System, CTS), которую должны использовать все языки ориентированные на CLR.. Общеязыковая спецификация (Common Language Specification, CLS) определяет правила, которым должны следовать разработчики компиляторов, чтобы их языки интегрировались с другими.
   Специально для платформы .NET был разработан новый язык программирования C#, синтаксис которого очень похож на синтаксис Java. Основными особенностями C# являются: отсутствие указателей, автоматическое управление памятью, встроенные синтаксический конструкции для работы с перечислениями, структурами и свойствами классов, возможность перегрузки операторов, поддержка использования программных интерфейсов, возможность присваивания типам атрибутов.
   Когда с помощью компилятора для платформы .NET создается модуль DLL или EXE, в нем содержится сборка на языке IL. Помимо инструкций IL, модули .NET содержат также метаданные, которые подробно описывают все типы (классы), использованные в модуле, также полностью описываются все методы, свойства и события этого типа. Метаданные описывают не только типы, используемые в сборке, но и саму сборку. Эта часть метаданных называется манифестом. В манифесте содержится информация о текущей версии сборки, об использованных ограничениях по безопасности, о поддерживаемом естественном языке, а также список всех внешних сборок, которые потребуются для нормального выполнения. Таким образом, сборка является самоописываемой. Благодаря манифесту устраняется проблема с версиями и значительно упрощается развертывания приложения в системе.
   .NET Remoting – это объектно-ориентированная архитектура для поддержки распределенных приложений в Microsoft .NET [2]. Эта архитектура значительно упрощает, или, лучше того, организует, методы создания и расширения распределенных приложений [2] по сравнению с DCOM. .NET Remoting поддерживает множество стандартных сценариев, требуя лишь незначительных объемов работы или настройки. Это позволяет легко получить работоспособное распределенное приложение. Приложение может строиться из подключаемых модулей, поддерживающих определенный интерфейс подключения, например, можно подключить нужный тип канала (например, HTTP или TCP) и тип форматировщика (бинарный или SOAP). Таким образом можно выбирать из стандартных, но мощных конфигураций, просто подключая другой модуль. В настоящее время поддерживается несколько вариантов настройки распределенных приложений. Первый вариант – с помощью конфигурационных файлов. Настройка удаленного взаимодействия легко выполняется посредством файлов в формате XML. Эти файлы позволяют также выполнять установку приложения на компьютер путем простого копирования дерева каталогов и кроме того, они значительно облегчают сопровождение приложения. Второй вариант настройки это программный. Если изменение настройки распределенного приложения нежелательно, то можно полностью управлять им непосредственно из кода программы.
   Модель защиты для систем .NET Remoting существенно изменилась по сравнению со сложной и требующей больших объемов настройки модели DCOM. На данный момент предлагается помещать удаленный сервер внутрь IIS (Internet Information Services – информационные сервисы Интернет), что позволяет использовать его средства защиты, не внося изменения в код клиента или сервера. IIS предоставляет поддержку различных механизмов аутентификации, в том числе Windows-интегрированную (NTML), базовую, Passport и на основе сертификатов. Предоставляется также защита секретных данных, передаваемых между удаленными компьютерами, на основе SSL (Secure Sockets Layer). В настоящее время в .NET Remoting нет готового механизма защиты для распределенных приложений, не использующих IIS, однако архитектура подключаемых модулей позволяет написать собственный модуль защиты.

   В .NET при исполнении приложения CLR выполняет контроль типов в коде и проверяет, не обращается ли код к недопустимым адресам, поэтому несколько приложений могут исполняться внутри одного процесса с сохранением тех же преимуществ изоляции приложений, что и в модели «одно приложение – один процесс». CLR определяет для приложений логическое подразделение: домен приложения. Код и объекты исполняющиеся в одном домене приложения, не имеют непосредственного доступа к коду и объектам, исполняющимся в другом домене приложения. Это обеспечивает защиту, так как сбой в одном домене не влияет на другие домены в том же процессе. Разделение между доменами приложения формирует границу .NET Remoting.
   .NET Remoting позволяет объктам, исполняющимся внутри разных доменов приложений, взаимодействовать друг с другом через границы .NET Remoting. С точки зрения инфраструктуры .NET Remoting объекты делятся на две категории: дистанцируемые и недистанцируемые. Экземпляры недистанцируемых типов не могут пересекать границы .NET Remoting ни при каких условиях. Разные категории дистанцируемых типов либо могут проникать через границы .NET Remoting, либо доступны через эти границы. .NET Remoting определяет такие категории дистанцируемых типов как передаваемые по значению и передаваемые по ссылке.
   Экземпляры типов, передаваемых по значению, пересекают границы .NET Remoting с помощью процесса, известного под названием сериализация, при которой текущее состояние объекта представляется в виде последовательности бит. После того как объект сериализован, он пересылается через границы .NET Remoting в другой домен приложения. в .NET Remoting тип считается если он объявлен с атрибутом Serializable.
   При передаче по ссылке все вызовы объекта, созданного в некотором домене приложения, обращаются именно к экземляру в данном домене, а не к его копии в другом домене. Чтобы сделать объект передаваемым по ссылке, достаточно его наследовать от System.MarshalByRefObject. Прежде чем работать с экземпляром дистанцируемого типа, его следует создать и инициализировать путем активизации. В .NET Remoting типы, передаваемые по ссылке, поддерживают два вида активизации: серверную и клиентскую. Типы, передаваемые по значению, не требуют особого механизма активизации, так как они копируются в процессе сериализации и активизируются в процессе десериализации. Режим активизации определяется не самим типом, а настройкой инфрастуктуры.
   Типы активизируемые сервером называются общеизвестными, так как серверный процесс, в котором находятся дистанцируемые типы, публикует их по определенным общеизвестным конечным точкам или адресам и активизирует экземпляры типа только при необходимости. .NET Remoting поддерживает два режима серверной активизации Singleton и SingleCall.
   В режиме Singleton в отдельный момент времени может быть активен только один экземпляр типа, который активизируется при первом обращении к нему клиента в отсутствии другого экземпляра. Экземпляр такого типа способен сохранять состояние в промежутке между вызовами. В режиме SingleCall обеспечивается модель программирования без сохранения состояния. Для типа, сконфигурированного как SingleCall, инфраструктура будет активизировать новый экземпляр при каждом вызове клиентом метода этого типа. После того как вызов метода обработан, экземпляр типа становиться доступным сборщику мусора.
   Когда необходимо, чтобы клиент работал с отдельным экземпляром удаленного объекта, используется клиентская активизация. Экземпляры таких типов могут оставаться активными в промежутках между вызовами методов и сохранять состояние.
   Для управления временем жизни удаленных объектов .NET Remoting использует вариант распределенной сборки мусора на основе лицензий. Лицензия – это объект, инкапсулирующий значения TimeSpan, которое содержит время жизни объекта. В каждом домене приложений имеется диспетчер лицензий, управляющий лицензиями экземпляров дистанцируемых объектов этого домена. При активизации удаленного объекта его лицензия передается диспетчеру лицензий, который периодически просматривает список лицензий, сравнивая время окончания действия лицензий с текущим временем. Каждая лицензия, срок действия которой истек, уведомляется об этом диспетчером лицензий, после чего она пытается себя продлить, опрашивая своих спонсоров. Если у лицензии нет спонсоров или никто ее не продлил, то она отменяет себя. Если лицензия объекта истекла, то она удаляется вместе с объектом, которому принадлежит. Спонсорами являются клиенты, которые подписываются на необходимый им удаленный объект. Для того чтобы передать объект по ссылке .NET Remoting выполняет создает экземпляр типа System.Runtime.Remoting.ObjRef и передает его по значению в целевой домен, где на основе этого типа создается объект-прокси (заместитель), посредством которого клиент может обращаться к удаленному объекту. ObjRef содержит метаданные передаваемого по ссылке объекта. При активизации экземпляра объекта, передаваемого по ссылке .NET Remoting назначает ему URI (Uniform Resource Identifier – унифицированный идентификатор ресурса), используемый клиентом при всех последующих обращения по ссылке на данный объект. Для непосредственной пересылки объектов через границы .NET Remoting используются каналы.
   Клиент, для взаимодействия с удаленным объектом, использует два вида прокси: прозрачный (TransparentProxy) и реальный (RealProxy). Клиент имеет непосредственный доступ к прозрачному прокси, который создается по информации из ObjRef с интерфейсом идентичным интерфейсу удаленного объекта. При вызове клиентом метода прозрачного прокси последний преобразует вызов в объект-сообщение и передает его реальному прокси, который отправляет его инфраструктуре .NET Remoting для доставки удаленному объекту.
   .NET Remoting пересылает сериализованные объекты-сообщения через границы посредством каналов, которые предоставляют транспортный механизм, обладающий большими возможностями по расширению и потенциальной возможностью поддержки самых разнообразных протоколов и сетевых форматов данных. Есть два стандартных типа канала: TCP и HTTP. Перед тем как сообщение будет передано в канал проходит через цепочку канальных приемников. Первым приемником является форматирующий приемник, отвечающий за сериализацию объекта-сообщения в поток байт определенного сетевого формата данных. Затем форматирующий приемник передает поток для дальнейшей обработки следующему приемнику в цепочке. Последний приемник в цепочке отвечает за пересылку потока байт по сети с использование определенного транспортного протокола. .NET Remoting предоставляет два типа форматирующих приемников: бинарный (BinaryFormatter) и SOAP-формата (SoapFormatter).